| From: | Steffen |
| Date: | 08 Aug 99 at 19:13:18 |
| Subject: | Re: Drawing images on Intution |
From: Steffen <steffen.mars@stenloese.mail.telia.com>
Hello Allan
On 06-Aug-99, Allan Odgaard claimed:
> From: Allan Odgaard <Duff@DIKU.DK>
>
> On 06-Aug-99, Steffen wrote:
>
>>> I know that - it was the initial blit I was refering to, this will make your
>>> solution slow. [...]
>> Slow ??? It's half a second on AGA at 640x512x256 !
>
> I'm running 1024x768x16bit - and as said before, a gfx board can run out of
> memory, so a bitmap ends up in fast mem, which requires a processor move for
> each blit. So making the backup will take seconds, and each blit from the off
> screen buffer will also be much slower than a simpel chip mem blit.
> But even if you don't want to be "compatible" with gfx cards, then I think half
> a second is totally unacceptable - imagine that the workbench froze for that
> amount of time, each time you wanted to drag an icon, because it had to make a
> copy of the entire screen?
Is it only possible to open a 1024x768x16 display on a gfx-board ? As i said, 1/2 second on 640x512x256 on AGA. This should be faster on a gfx-board. It should still be as gfx-board compatible as most aplications, as we are still just using system calls. I can't see how you can conclude that the method is not compatible with a gfx-cards. Just because you have several aplications open leaving you too little gfx-mem to start a game, doesn't make the game gfx-card 'incompatible'. Furthermore, i am not under the impression that my WB freezes because the blitter blits ? I thought that was one of the advantages of the custom chips on Amiga.
>> I disagree that your method should make the
>> animation faster.
>
> I never said that the actual movement would be faster - even though it will if
> your huge buffer ends up in fast mem. I just said that restoring the
> background using RectFill for the gren area and blit in the cards on the rest
> is everything else than slow. Even when you have 52 cards to manage. So you
> should not jump to clumsy solutions in a naive believe that it may be faster.
I can not see why you keep asuming the game will run 1024x768x16, wich seems to be the foundation of why my suggestion seems 'clumsy' to you. I don't see either, why your method should be any faster or significantly mem-saving compared to just making a copy of the area destroyed by the card, and bliting it back when needed. If deciding to use a pattern on the display, your method would be even slower.
>> But we're talking about making fast graphics, for wich simple- and smart
>
> I'm talking about how to restore the background while dragging around a card,
> in a system friendly application, which runs in a window.
If it was a requirement that the game should run in a window, i've missed it. I thought the question was how to do it the fast way. Perhaps the author of this subject could clarify this ?
>> refresh is not suitable, you should use superbitmap, and in that case, the
>> above is not true.
>
> Superbitmaps are not much different from smart refresh. A super bitmap just has
> the ability to exceed your windows dimension, thus allow scrolling and drawing
> outside the window boundaries. But the gfx. will then be splitted over two
> bitmaps, the same is also the case when a window cover your superbitmap.
> I see absolutely no advantages in a superbitmap for the cardset game, and the
> claims I made about not using BltBitMap() with window bitmaps also hold for
> superbitmaps.
Having a dimension larger than the displayable is ONE of the features of superbitmap windows. Another is that the display can allways be recreated by the information of the superbitmap itself, wich is the reason it is refered to as a refresh mode. You should check your information about superbitmap windows, and get back to me.
>> Actually, the window should be a backdrop window on a
>> seperate screen (if you want speed).
>
> Could you specify the technical reason for this?
When a window is backdrop, it does not overlap any other windows. Therefor, you don't have to take the backdrop window into account when calculating wich window is overlaping the other. Allso, it is not needed to render the screen, when you have a backdrop window on that screen, because the window overlaps the entire screen. Furthermore, the backdrop window actually uses the screens bitmap wich (via mcp) can be directed to be interleaved (if the programmer hasn't asked for it specificly). I haven't checked this, but i bet you, if you check for it, you'll find backdrop windows are actually superbitmaps.
> Regards Allan
> --
L8R
Steffen :Q